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Abstract 

Collection One of the PL/l Roundtable contains informal remarks 
on several PL/l issues. The conceptual basis of PL/l and its development 
history are noted for background information. The significance of PL/l 
for both quasi-programmers and professional programmers is discussed 
and several technical problems relating to implementation, the host 
operating system and efficiency are raised. Also included is a concise 
comparison of PL/l and COBOL. 
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Preface 

The PL/l Roundtable is a collection of informal remarks on PL/l. 
At this time there has been no attempt to correlate the contributions or to 
mold them into a single, continuous presentation. Rather, the intent of 
this document is to provide a mechanism for collecting reactions, sus- 
picions and discoveries relative to PL/l as a result of work by COMPASS 
staff members with PL/l since its inception. This document is labelled 
"Collection One" because several of us wish to comment further 
and these comments will probably be collected together as "Collection 
Two". PL/l being what it is, there is a likelihood that this flow of reactions 
and discoveries will continue, so we have left open the possibilities of 
further collections of the PL/l Roundtable . 

R.W.M. 
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The Conceptual Basis of PL/l 
Carlos Christensen 



PL/l brings together, in a single unified programming language, facilities 
for programming in three areas of application: 

scientific computing, 
business data processing, and 
systems programming. 

These areas of computing application have previously been served by 
separate programming languages , and the task of designing PL/l consisted 
of studying existing languages, rationalizing the conflicts which arose, 
and joining their various facilities in a single language. Although PL/l 
does contain some unique and novel features, it principally represents an 
outstanding effort toward the synthesis of existing and well-known program- 
ming features. 

We will first consider the sources on which PL/l drew in each of 
the three applications areas mentioned above. In the area of scientific 
computing , PL/l had well-developed and well-known precedents in FORTRAN, 
ALGOL, and others. At the time PL/l development began, FORTRAN IV and 
ALGOL 60 were complete and well-specified languages, and many of their 
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unsuspected advantages and shortcomings had come to light. Although 
the designers of PL/l did extend and generalize some features of FORTRAN 
and ALGOL, a "purely scientific" program in PL/l program is quite intel- 
ligible to a programmer who is familiar with either FORTRAN or ALGOL. 

In the area of business data processing , PL/l also had a well 
established precedent in COBOL. COBOL was the first high-level pro- 
gramming language to receive a careful definition intended for use by the 
entire computing community, and this definition was available to the 
designers of PL/l. COBOL' s contribution was principally in the areas of 
data description and input-output. Since FORTRAN and ALGOL had 
relatively primitive facilities in this area, it was possible to accept 
COBOL' s contribution without serious conflict. On the other hand, COBOL's 
"English-like" language for arithmetic expressions ('ADD A TO B GIVING 
C) was in direct conflict with scientific programming language CC = A+B'), 
and it was discarded. 

In the area of systems programming, PL/l did not have a generally 
accepted precedent. Although systems programming has a long history and 
although many appropriate languages have been produced, no useful widely 
accepted standard has appeared. Instead, this area is crowded with com- 
peting languages, none of which can claim to be representative of the whole 
area. Accordingly, the designers of PL/l included a minimum, primitive 
facility for the list-processing, bit-picking and interrupt-handling required 
by systems programmers. The list processing capability is in many ways 
similar to the arbitrary linking of arbitrary nodes in L6 and CORAL. 
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Thus PL/l is net related in the same way to each of the three appli- 
cations mentioned above. For scientific computing and business data 
processing, it represents a synthesis of some very advanced and powerful 
programming features and purports to represent a final disposition and 
consensus in these areas. For systems-programming, it represents a 
basic facility from which the PL/l programmer can build, but does not 
offer him truly 'high-level' user-oriented facilities. 

We have considered the way in which the PL/l facilities were drawn 
from sources in each of the applications areas. The remaining problem was 
the joining of these facilities into a single integrated programming language, 
Here the really basic issues of programming language design arose: the 
character set for the language, the structuring of the program, the incor- 
poration of operating system features into the language, the flow of control 
in the program, and so on. Initially, the design committee attempted to 
adopt FORTRAN as its basic language model; but as work progressed, the 
basic model moved more and more toward ALGOL until only a residue of 
FORTRAN concepts remained. 

PL/l resembles FORTRAN in certain immediately apparent but 
relatively unimportant aspects, as follows:" 

PL/l uses ,in addition to special characters and digits, only upper 
case letters, while ALGOL made use of lower case, upper case, and 
bold face letters; 

PL/l uses the keywords of FORTRAN rather than those of ALGOL. 
For example, a loop in PL/l and FORTRAN begins with 'DO', while 
it begins with 'FOR' in ALGOL; and 
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PL/I similarly carries over some of the uses of special characters 
from FORTRAN. For example, exponentiation is '**' , while it is 
'f ' in ALGOL. 

The programmer should not be deceived by these superficial similarities. 
PL/l started out to be FORTRAN VI, but it has become something very 
different indeed. 

On the other hand, PL/l resembles ALGOL 60 in some very basic 
and important ways, as follows: 

PL/l is a format-free language, as is ALGOL; that is, it does not 
depend on card columns for its interpretation as does FORTRAN; 

PL/l is heavily dependent on the concept of declaration of identifiers, 
which was first introduced and proved in ALGOL; 

PL/l uses "block structure" to gather a sequence of statements 
together into a single unit and to control the scope of declaration; and 

PL/l uses a method of subroutine definition which is an improved 
and extended version of the ALGOL procedure definition. 

In many ways, then, PL/l is an improved and extended version of ALGOL. 
ALGOL has been described in a widely available paper*, and that paper is 
recommended as collateral reading for the study of PL/l. 



* Naur, Peter (Ed.) Revised report on the algorithmic language ALGOL 60. 
Comm. ACM 6 (January 1963), 1-17. 
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The designers Of Pl/l did not, however, accept ALGOL uncritically 
as a linguistic framework forPL/l. They recognized and, for the most part, 
corrected the known defects of ALGOL. 

For example, 

Integer labels were eliminated because they are easily confused 
with problem data; 

The loop parameters were defined statically instead of dynamically 
to avoid confusing anomalies; 

"Call-by-name" was restricted to eliminate cases which cannot be 
implemented efficiently;. 

The assumption that all procedures and functions could be used 
recursively was dropped as an unnecessary bookkeeping expense; 

Side effects within the evaluation of an expression were defined in 
a simpler way; and 

Declaration of formal parameters was made mandatory. 

Thus the designers of PL/l drew on the experience which had been gained 
from the "ALGOL experiment" to produce a linguistic base for PL/l which 
is superior to ALGOL. 
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The History of PL/l 
R.W. Mitchell 

The development of PL/l is an outgrowth of a longstanding desire 
in the SHARE FORTRAN project for a more complete, less restrictive language, 
The original language specifications in spring of 1964 were easily rec- 
ognizable as an extension of FORTRAN. The language has undergone many 
revisions since then and now more closely resembles a conglomerate of 
FORTRAN, ALGOL, and COBOL. 

The three major areas of the PL/l history are language specification, 
industry activity, and compiler development. The following notes the 
major events in each area. 



Industry Activity 
October 1963 - 



May 1964 - 

August 1964 - 

March 1965 - 
March 1965 - 



August 1965 - 



SHARE/IBM 3x3 Committee on advanced language 
development formed, all members of systems and 
scientific programming background. 

3x3 Committee expanded by including a GUIDE 
representative and some of the more vocal res- 
ponders to Report 1 . 

SHARE NPL Project formed with many SHARE partic- 
ipants , one CO-OP observer and one X3.4.3.1/ 
Honeywell observer. 

SHARE closes door to all outside observers . 

X3.4 votes 'NO' on any NPL activity other than 
observing progress, this was after an offer of 
complete information (but no control) from IBM 
and prolonged debate on language development vs . 
de facto standardization vs. official standardization. 

BEMA/X3.4 sponsored tutorial on PL/l. 
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January 1966 - 
February 1966 

March 1966 - 
April 1966 - 

June 1966 - 



X3.4 votes to encourage some industry wide 
activity on PL/l. 

BEMA sponsored open meeting of formation of a 
industry activity on PL/l, alternatives were dis- 
cussed and activity under X3.4 recommended. 

X3 ,X3 . 4 approve PL/l committee . 

X3.4.2C formed to discuss and evaluate PL/l 
and its specification relative to standardization. 

X3.4.2C forms subcommittees 

X3.4.2C1 Language Development 
X3.4.2C2 Formal Definition 
X3.4.2C3 Subset Specifications 



Language Specifications 
March 1964 - 



June 1964 - 



SHARE Report 1; Expanded FORTRAN, System/360 
limits on data. 

SHARE Report 2; data structures, report generator, 
removal of System/360 restrictions. 



December 1964 - NPL Technical Report; complete revision, more 

complete, delete logical data type, BEGIN-END 
blocks added. 



March 1965 - 



PL/l - SRL-0; complete revision, first machine 
producible specification. 
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May 1965 - 
January 1966 - 

June 1966 - 



July 1966 - 
October 1966 - 

November 1966 - 

December 1966 - 



January 1967 - 
January 1967 - 



PL/l -SRL-1; Cleanup of SRL-0, delete sort and 
report generation. 

PL/l - SRL-2; pointer data, completely new I/O, 
asynchronous operations , removal of dynamic 
fetching and deleting of programs . 

PI/I Concrete Syntax (TN 3001) and PL/l 
Abstract Syntax (TN 3002); first reports of new 
semi-formal definition (circa SRL-2). 

PL/l SRL-3; first implications of F compiler. 

PL/l Translator (TN 3003); more of semi -formal 
definition (circa SRL-3). 

PL/l Interpreter (TN 3004); more of semi-formal 
definition (circa SRL-3). 

PL/l - SRL-4; moving character strings below 
arithmetic data in the data hierarchy, deletion 
of binary pictures . 

Formal Definition of PL/l (TR 25.071 - Ver I). 

Revised TN 3001. 



Compiler Development 

Spring 1965 - PL/l Subset by Knuth using TMG (IBM 7090) 
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? 1965 - 

Fall 1965 - 
Fall 1965 - 

Summer 1966 
Summer 1966 

Summer 1967 

? _ 
? _ 
? _ 



SLANG produced compiler, not satisfactory for 
production use (S/360) 

NICOL 1 (IBM 7090) 

Stanford Subset PL/l (FORTRAN and ALGOL features) 
(IBM 7090) 

PL/I (F) (S/360) 

EPL (BTL) for MULTICS development (GE 635) 

PL/I (D) (S/360) 

Digitek PL/l (GE 635/645, SIGMA 7). 
RCA Subset (Spectra 70) 
Univac Subset ( ? ) 



-9- 



A Comparison Between PL/l and COBOL 
Caral Sampson 

The following is a comparison between PL/l and COBOL. The 
material is taken from "A Guide to PL/l for Commercial Programmers" , 
C20-1651-0, published by International Business Machines Corporation. 
The comparison is divided into the following categories: language notation, 
program structure, data description, data manipulation, and input/output. 

Language Notation 

In general, both languages employ similar notations: programmer- 
defined words use alphabetic characters and decimal digits; expressions 
consist of sequences of names, constants, and operators; keywords 
identify language elements; punctuation characters separate elements; 
statements have an English-like appearance. However, the notation 
rules of both languages do differ; the following list contains some of the 
more significant differences . 

1. In both PL/l and COBOL, keywords have preassigned 
meanings. In COBOL, keywords are reserved for their intended 
purpose and cannot be used for other purposes. In PL/l, however, 
keywords are not reserved for special purposes and may appear 
wherever a programmer-defined word is permitted; for example , the 
keyword READ may be used in a PL/l program as the name of a file. 
In PL/l, different meanings for the same word are determined from 
context . 

2. COBOL requires a programming form, PL/l does not. In 
PL/l, punctuation! characters determine the significance and 
grouping of language elements . This permits PL/l programs to be 
treated as long strings of characters and to be transmitted to a 
computer by means of almost any input medium . 

3. In COBOL, blank characters must surround arithmetic 
operators; this is not required in PL/l. In PL/l, blank characters 
are only required between successive words that are not separated 
by special characters such as parentheses, operators, and punctua- 
tion characters . 
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4. COBOL restricts comments to the Procedure Division 
and requires that they be written in a NOTE statement. PL/l 
allows comments to appear throughout the entire program and 
permits them to be used wherever blank characters may appear 
(except in a character string constant or in a picture specification) . 

5. The COBOL character set consists of 51 characters; PL/l 
uses 60 characters . 

The following points show some of the less significant differences: 

1 . PL/l terminates all statements with a semicolon; COBOL 
terminates statements with either a period, a comma, or a semicolon. 

2 . Programmer-defined words in COBOL must not be longer 
that 30 characters; in PL/l the limit is 31 characters. 

3. PL/l uses the break character (an underscore) within 
programmer-defined words to improve readability; COBOL uses the 
hyphen. 

Program Structure 

Although both programs are constructed in problem-oriented terms and 
employ the statement as the basic program element for processing data and 
for altering the sequence of program execution, it is in the area of program 
construction that PL/l and COBOL differ the most. The following list 
points out some of the more significant differences in the program structure 
of the two languages . 

1. In general, a COBOL program is equivalent to one external 
procedure in PL/l. The Data Division and the Environment Division 
of COBOL correspond for the most part to the DECLARE statement 

in PL/l. The COBOL Procedure Division is equivalent to the 

executable statements in a PL/l procedure. The function served 

by the COBOL Identification Division is provided in PL/l by comments, 

2. The ENTER statement in COBOL is equivalent to the CALL 
statement in PL/l when the CALL statement is used to activate 
separately compiled external procedures . However, the concept of 
nested procedure blocks (internal procedure blocks) in PL/l has 

no counterpart in COBOL. Consequently, it is not possible 

within the same COBOL source program to define internal subprograms 

to which arguments may be assigned. 
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3. COBOL does not provide the equivalent PL/l facilities for 
automatic and controlled allocation of storage. 

4. The AT END, INVALID KEY, and SIZE ERROR options in 
COBOL are provided in PL/l by the ON statement. However, PL/l 
provides a fuller range of interruption conditions than does COBOL . 

5 . The effect of the ALTER statement in COBOL is achieved 
in PL/l by assigning a label constant to the label name in a GO 
TO statement. 

6. The PERFORM statement in COBOL and the DO statement 

in PL/l may be used for similar purposes. The PERFORM statement, 
however, is used for out-of-line loop control whereas the DO 
statement is used for in-line loop control. 

Data Description 

In general, both languages use similar methods for describing the 
characteristics of data items stored within a computer: programmer-defined 
words are used to name data items; keywords specify the characteristics 
of named data items; data items may be collected into aggregates; 
constants may be specified for each data type; data names may be assigned 
initial values; and a picture specification may serve as an alternative 
method for describing data. There are differences, however, between the 
data description features of both languages; the following points contain 
some of the more significant differences. 

1. COBOL describes data in the Data Division; PL/l uses the 
DECLARE statement. The COBOL Data Division contains separate 
sections for different kinds of data; PL/l does not require a separation 
of the various data types in a DECLARE statement. 

2. COBOL requires all programmer-supplied words to be defined 
in the Data Division. PL/l allows programmer- supplied words to be 
used in a program without being defined in a DECLARE statement; the 
meaning of such words is determined from context and a complete 

set of default rules is used to determine unspecified data characteristics . 

3. In COBOL, the description of data on external storage media 
is specified in the Data Division. In PL/l, the input/output 
statements specify the description of externally stored data. 
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4. Bit strings and label data are PL/l data types not contained 
in COBOL. 

5. COBOL uses figurative constants; PL/l does not. 

6. PL/l imposes no limit on the number of dimensions in an 
array or on the number of levels in a structure. COBOL limits a 
table (the COBOL equivalent of a PL/l array) to a maximum of three 
dimensions and a group (the COBOL equivalent to a PL/l structure) 
to a maximum of 49 levels. 

7. The order of name qualifiers in COBOL is the reverse of 
the order used in PL/l. COBOL uses the keywords IN and OF as 
qualification operators; PL/l uses the period. 

Data Manipulation 

Both languages use expressions to specify data calculations and the 
picture specification to edit data. However, PL/l uses a single statement 
for all types of data manipulation, whereas COBOL uses several different 
statements. The following list contains some of the more significant 
differences in the data manipulation features of both languages. 

1. The effects of the COBOL statements MOVE, COMPUTE, 
ADD, SUBTRACT, MULTIPLY, and DIVIDE are achieved in PL/l 

with the assignment statement. However, when the MOVE statement 
in COBOL is used with groups (the equivalent of PL/l structures) , 
data is moved without regard to the level structure of the groups , and 
data conversion, if specified, is ignored. When the assignment 
statement in PL/l is applied to structures, the assignment is 
performed elementary item by elementary item and all data conversion 
is done as specified. 

2 . The BY NAME option in PL/l is similar to the CORRESPONDING 
option in COBOL. 

3. PL/l permits expressions to use data items that contain edit 
characters. COBOL does not provide this feature. 

4. The bit string operators in PL/l are similar to the logical 
operators in COBOL. However, COBOL has no data type that 
corresponds to the bit string data type of PL/l. 
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5 . The concatenation operator of PL/l is not available in 
COBOL. 

Input/Output 

Both languages employ similar methods for transmitting data between 
internal and external storage areas to the extent that input/output statements 
process files and identification records (label records) in files may be 
processed both on input and on output. The languages differ, however, in 
input/output capabilities; the following points cover some of the more 
significant differences . 

1. In COBOL, data transmission implies files that are composed 
of logical records . One or more data items form a logical record; 
data is transmitted one logical record at a time. 

PL/l provides two types of data transmission. Record-oriented 
transmission, like COBOL, deals with logical records. Stream- 
oriented transmission handles individual data items; a file is 
thought of as one continuous stream of data items rather than as a 
collection of logical records . 

2. PL/l provides control format specifications that regulate 
printing and spacing operations. 

3. In PL/l, identification records (label records) are read or 
written as a result of the IDENT option in an OPEN or CLOSE 
statement. In COBOL, label records are specified by a file 
description entry in the Data Division, and special label procedures 
are specified in a USE statement. 

4. COBOL permits a file name to be used as a name qualifier; 
PL/l does not. 

5. In PL/l, the characteristics of a file are specified in a 
DECLARE statement or an OPEN statement. In COBOL, file character- 
istics are specified in a file description entry in the Data Division. 
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The Operating System as a Host for PL/l 
Mathew Myszewski 

The PL/l language consists of an impressive array of facilities. 
While it is conceivable that a single Pl/l processor could be built to 
run on a given barefoot machine, a more likely possibility is that a given 
Pl/l processor will delegate some of its functions to the operating system 
which forms its environment. In general, the division of labor will vary 
according to the power of the operating system and other resources 
available. However, there is no doubt that powerful facilities for I/O, 
resource allocation, linkage, and control must be provided, if not in 
the PL/l processor environment proper, then in the processor itself. The 
next few sections will outline these facilities and how they shape both 
the environment and processor. 

The PL/l facilities for input and output require an assortment of 
features, some which tax all but the most comprehensive of operating 
systems. Files, of course, are symbolically referenced, but surprisingly, 
are defined statically. Thus, one could not read the name of a file at 
execution time and then access it. However, one is allowed to change 
other file attributes dynamically. 

Random-access is required by the PL/l UPDATE file function 
attribute, the KEYED file attribute, and the DIRECT file access attribute, 
as well as by the DELETE and REWRITE statements . The BACKWARDS attri- 
bute requires access in the reverse order. A primitive form of non-selective 
file protection is provided by the UNLOCK statement and the EXCLUSIVE 
attributes however, this in itself requires some degree of sophistication 
either in the environment or in the interface to the environment. 
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Resource allocation is implied directly by the CONTROLLED and 
AUTOMATIC attributes. Many other features indirectly require either 
dynamic or static allocation for data and more especially for bookkeeping 
information. A list of such features, which is by no means complete, 
would include the RECURSIVE attribute, the VARYING string attribute, 
the BUFFERED file attribute, DATA-directed input/output, multiple ENTRY 
points , the TASK options , and dope vectors which keep track of array 
bounds. Some of these topics will be treated in more depth under the 
topic "Some Major Efficiency Questions in Pl/l" . 

Linkage of the usual sort, i.e. procedure-to-procedure and pro- 
cedure-to-data is required in PL/l. This linkage, for the most part, may 
be performed prior to execution, as the number, names, and size of 
external procedures and external data are all known at that time, and hence 
these objects may be located statically. 

Control of flow in PL/l has some rather sophisticated aspects. 
Parallel paths may be accomplished through use of the TASK option, TASK 
attribute, the EVENT option, and the PRIORITY option . However, only 
strict hierarchical control is allowed, i.e. orphan tasks are not permitted. 
Interrupt actions may be controlled through the use of the ON and REVERT 
statements, condition prefixes, and the SIGNAL statement. Again, control 
is tightly linked to the static program structure and the automatic stacking 
of a given condition may be done at most once per block. 

The requirement for environmental support is but one aspect of the 
question of hosts of PL/l. Another equally important question is whether 
PL/l precludes the use of available operating system capabilities. We have 
already mentioned above operating system facilities such as orphan tasks 
which may exist in operating systems but not in PL/l. However, we are less 
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concerned that PL/l does not contain all possible variations of all con- 
ceivable features. Rather, we are concerned with the "features" which 
in effect prevent efficient matching of resources to programs . 

In particular, either the LABEL variable or the POINTER variable, 
especially when combined with the CELL concept, virtually prevent dynamic 
reallocation of data or procedures unless some paging mechanism is used. 
This is due to the fact that any movement of a piece of data implies the up- 
date of all pointers referencing it. However, the CELL attribute allows 
arbitrary overlay of pointers with other data. So even were it known which 
pointers referenced a data element or structure, one could not update these 
without knowing whether or not it were a CELL currently containing a particular 
pointer value. This, at least to my knowledge, would entail a prohibitive 
amount of bookkeeping. A similar argument applies to reallocation of pro- 
cedures and the LABEL variable. 

Other questions of efficiency will be covered under the topic 
"Some Major Efficiency Questions in PL/l" . Questions of user protection 
will be covered under the topic "Freedom of Expression is not License for 
Anarchy". 

The set of transactions between a PL/l processor and an operating 
system is a large set indeed. How can one hope for an efficient interface 
if PL/l and the operating system have been developed independently? Surely 
obtaining a well-matched system would befortuitous under such conditions. 
The same argument must be applied to the design of language without regard 
to its efficient compilation. In short, one should not paste together compon- 
ents designed independently of one another and expect a good programming 
system to result, no matter how good the individual designs might be. 
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Some Major Efficiency Questions In PL/l 
Mathew Myszewski 

PL/l "... is a language designed for efficiency, a language that 
enables the programmer to use virtually all the power of his computer."* 
The two main questions we are concerned with are the following: To what 
extent do greater generality and more features make code optimization 
necessary? Impossible? To what extent do greater generality and more 
features require more storage space ? 

Before answering the first question, it would be well to explain 
what is meant by it. If a language has mostly special cases, a compiler 
may fairly easily produce good code for the one or two possible forms 
(e.g. the FORTRAN DO statement). As one adds generality, it is not a 
straightforward matter to determine the special (but frequently used) cases 
and produce efficient code for them. For example, the PL/l DO statement 
allows multiple index specifications. Were one to compile all cases 
identically, the simple case would result in at least two extra transfer 
instructions per loop. In the case of pointers, side effects may be pro- 
duced which make it impossible to reorder computations for greatest 
efficiency of execution. The result of such generality then, is not necessarily 
more efficient compilers, but quite possibly compilers which either do not 
optimize, cannot optimize, or do so at some considerable increase in com- 
piler size, complexity, and running time. Bear in mind that we are only_ con- 
sidering optimization which we have come to expect in other more simple 
languages . 

Before leaving the subject of loops completely, it should be noted 
that PL/l allows the programmer to modify the loop index within the loop. 
In order to avoid excessive register loading for the common case, one must 
keep track of any possible changes to the index from functions with side- 
effects, etc. 



* IBM Systems Reference Library, IBM System/360 Operating System, PL/l 
Language Specifications, File No. S360-29, Form C28-6571-4, p. 9. 
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Although the cost of calling a function or subroutine should be small 
in relation to the size of the subroutine, several factors combine to make 
prologue and epilogue coding large. A brief list would include: r eentrant 
jsave -re s tore code, initial value loading, passing of parameters whose 
extents are to be computed, AUTOMATIC data, ON-conditions {all the 
standard ON-conditions are probably pushed whether or not they are used 
in the procedure), multiple entry points, and multiple returns. To give an 
example of how any one of these considerations can increase running time, 
we will look at multiple entry points. Since each entry point may have 
different parameters in different order, or have different function attributes, 
it is necessary to sort the parameters into some canonical order and record 
the data type to be returned. At the return statement it is determined dynam- 
ically which data type is to be returned and conversion is performed to this 
type. These determinations cannot be made at compile time and thus result 
in code . 

The second question, that of storage, is as the first question, 
largely dependent on the particular implementation; in most cases, however, 
added storage will be needed to implement the features described here. 
For example, code produced without optimization will take more space, 
as discussed above. Again, we will list those features most apt to use 
extra space. Any use of the asterisk notation or expressions for bounds or 
length will necessitate storage for a dope vector for each instance of storage 
for the data. Prologues and epilogues can be as space-consuming as they 
are slow. Multiple entry points require at least n x m conversion routines 
where n is the number of different function data attributes and m is the num- 
ber of different data types returned in a given procedure. Any DATA-directed 
GET statement without a data list will create a table of all identifiers known 
at that point, plus all their attributes and extents . Lastly, a calling procedure 
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must contain a dope vector for at least each argument passed to a routine 
which uses the asterisk notation or expressions as bounds of length, 
and possible for all arguments. 

In short, PL/l will not come cheaply. Either compilers will have a 
great deal of special case machinery to distinguish the general case from 
the more common case or they will compile inefficient, space-consuming 
code. 
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Implications of PL/l for the Professional Programmer 
Caral Sampson 

Usually programmers are categorized by the application area 
in which they work. Thus one can speak of scientific, commercial, 
and systems programmers. Another method of classifying programmers 
is by their attitude towards the computer. Thus one can speak of non- 
professional and professional programmers. An arbitrary definition of 
this latter method of classification follows. 

The non-professional programmer considers the computer only 
as a means to an end. He is not interested in how the computer works 
or what its limitations are, except as these characteristics affect the 
perceived utility of the computer. His interest is solving his problem, and 
he views the computer much the same as a slide rule, desk calculator, 
tabulating equipment, or any other tool at his disposal. Moreover, the 
tremendous speed of the computer, coupled with its size, tends to impress 
the non-professional programmer to such a degree that he considers the 
computer infallible , forgetting it is a machine which can do only what it 
can be told, and is told, to do. 

On the other hand, the professional programmer is interested in 
the computer itself. He knows how it works and how to use it efficiently 
and effectively. He knows its limitations and sees to it that his problem 
does not exceed the limitations of the computer. The professional 
programmer knows that the computer is not infallible; it cannot be programmed 
to do many things which to the non-professional programmer seem possible, 
even if difficult. 

The non-professional programmers are usually subject-matter 
(scientific or commercial) oriented. The professional programmers are 
usually either students in a computer science curriculum, software 
developers , or software maintainers . The major distinction between 
non-professional and professional programmers is their attitude towards 
the computer rather than their application area. This paper considers 
the implications of PL/l for the professional programmer. 

One implication of PL/l for the professional programmer is that 
he has fewer languages, perhaps only one, to learn in detail. A design 
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objective of PL/l is to produce a language that encompasses scientific, 
commercial, real-time, and systems applications, thereby providing the 
programmer with a language capable of handling a broad range of applications 
Features and concepts in PL/l were taken from many existing languages. 
The data structure is from COBOL and JOVIAL. The procedure concept is 
from ALGOL. The pointer facilities are from the list processing languages. 
Although with PL/l, as it is being implemented, the programmer may have 
only one major language to master, this language is so complex that the 
programmer still will have to be knowledgeable in many programming 
techniques and concepts . 

Few programmers are intimately familiar with more than one 
type of high order language, and fewer with more than two. Types of 
high order languages include algebraic languages (such as FORTRAN and 
ALGOL), business languages (such as COBOL), list-processing languages 
(such as LISP and IPLV), formula manipulation languages (such as 
FORMAC) , and simulation languages (such as SIMSCRIPT) . A professional 
programmer who maintains the systems at a user installation is usually 
not proficient in more than two languages . He is generally well acquainted 
with the installation's operating system, assembly language, and prime 
algebraic language, usually FORTRAN. If the installation uses other 
languages, such as COBOL, the programmer knows enough about that 
language to build the proper system tape . It is unlikely that the programmer 
also knows a list processing language, a formula manipulation language, 
or even another algebraic language if the major algebraic language is 
FORTRAN. This type of professional programmer will find PL/l a rich 
language. He will discover a wealth of applications for features such as 
string data and data structures. The interrupt facilities, error correction 
functions, debugging features, and multi-tasking facilities will help him 
in writing the installation's accounting and other standard routines. Because 
PL/l is capable of handling a large range of applications, the professional 
programmer will find his knowledge of types of high order languages 
extended and it is likely he will find that PL/l suffices for most of his 
applications . 
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Another design goal of PL/l is to provide a language that enables 
the programmer to use virtually all the power of his computer. To help 
accomplish this PL/l provides facilities for techniques such as shared 
data processing, asychronous program execution, and real-time processing. 
However, these techniques are only useful when the operating environment 
has the proper facilities for data management, task management, and job 
management. Therefore the programmer will have to know in detail not 
only Pl/l, but the operating environment as well. 

To use the multi-tasking facility effectively the programmer must 
be aware of the relationship between tasks in his PL/l program and load 
modules in the operating system. The purpose of tasking is to allow more 
than one set of instructions to be operating asynchronously. If the 
hardware cannot do this , why use the feature in a PL/l program and pay for 
the overhead (in time and code) required for multi-tasking? Pl/l thus 
puts a greater demand on the programmer's awareness of the operating 
environment . 

With PL/l, the professional programmer will have to be fully 
aware of the characteristics of his particular computer. Pl/l data attributes 
are an important reflection of the host computer. In PL/l for the IBM 360, the 
FIXED DECIMAL data type reflects the packed data type and related 
character by character arithmetic operations of the computer. FDCED BINARY 
reflects the half word/full word data representation and related binary 
arithmetic operations . FLOAT data type (both DECIMAL and BINARY) 
reflects the machine floating point data and related arithmetic operations . 
To use efficiently the many data types (over 14 combinations of attributes) 
that can be specified in PL/l, the programmer must be aware of the machine 
representation and the type of arithmetic operations used with each. 

Because PL/l reflects the operating environment and allows the 
programmer to interact with the environment, he will be able to write many 
programs in PL/l that previously were written in machine code . PL/l 
provides interrupts for conversion errors on data and provides a series of 
functions and pseudo-variables to enable the programmer to determine the 
offending character, change the character, and then continue processing 
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using the new character. Previously on data errors the programmer 
resorted to assembly code. The interrupt conditions and the debugging 
facilities of PL/l will enable the programmer to do most of his debugging 
at the symbolic level. 

PL/l covers the largest areas of application of any language yet 
defined. The implementation problems are many. Most of these problems 
have been solved in some manner in other compilers prior to being addressed 
in PL/l. But these problems in combination have never been encountered 
or solved in one compiler. The IBM 360 Pl/l F level compiler is only the 
first of a long series of implementations. Before work can begin on better 
implementations the full language must be implemented. Thus the present 
compiler (and those in the near future) will generate poor quality code for 
many PL/l statements. The professional programmer must learn which 
statements are costly to use in terms of storage space and execution time, 
and develop guidelines for using the compiler efficiently. An example of 
inefficient versus efficient use of PL/l is a card to tape program described 
in the paper "The Quasi-Programmer and PL/l" . 

For the professional programmer PL/l also implies trips to conferences, 
published papers, job security, and job opportunities. PL/l is a new area 
of specialization. It is at the stage FORTRAN was in 1957, with everyone 
asking "How do I use it?", "Is it good?", "How do I use it efficiently?", 
"What does it cost me to use it?" The professional programmer has an 
opportunity to become an expert in PL/l and provide answers to some of the 
many questions being asked about PL/l. There is a lack of general PL/l 
literature as well as a lack of teaching aids and self study documents. 
The computer conferences and trade publications will be needing more and 
more papers on PL/l. The PL/l expert will find himself in great demand, 
probably more so than the FORTRAN expert of 1957 if only because PL/l 
is more complex than FORTRAN, the investment in it is greater, and the 
cost of using it is greater. 

In summary, the implications of PL/l for the professional programmer 
are: 

1. He will need to know fewer languages than previously, perhaps 
only one . 
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He will gain a broader knowledge of language and programming 

concepts . 

He will need a detailed understanding of his particular operating 

environment, both operating systems and hardware. 

He can program more things in a higher level language than 

previously. 

He has a golden opportunity to improve his professional 

reputation. 
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The Quasi-Programmer and PL/l 

Caral Sampson 

The paper "Implications of PL/l for the Professional Programmer" 
classifies programmers as non-professional or professional. The non- 
professional programmer is neither a beginner, a novice, nor a quasi- 
programmer. He is well trained in a discipline, recognizes that he is 
not a computer expert, and freely seeks the services of the professional 
programmer. There is also a class of programmer one may call a quasi- 
programmer. Th4e +tp° tV iinl , r c i hp ig a professional programmer or computer 
- — exnert r and is therefore dangerous in any computing facil ity. Some 
examples of quasi-programmers are: a programmer working in commercial 
data processing who has never heard of floating point arithmetic; the 
programmer who isn't interested in efficient compiler or computer usage; 
the programmer who refuses to switch from FORTRAN II and the FORTRAN 
monitor system to FORTRAN IV and IBSYS because IBSYS is too complicated 
to use; the FORTRAN programmer writing large programs who doesn't use 
subprograms. All of these are quasi-programmers. Time alone does not 
make a quasi-programmer into a professional programmer. His attitude 
towards his job and the computer are the determining factors. The quasi- 
programmer' s limited knowledge of computers, computer languages, compilers, 
and operating systems coupled with the multitude of PL/l statements , the 
multitude of data attributes, and PL/l's interaction with its operating 
environment, makes learning PL/l (even a subset) a difficult task. The 
quasi-programmer will have an even more difficult time using PL/l for 
meaningful work. During a recent series of lectures on Pl/l a member of 
the audience commented that each page of PL/l documentation should be 
stamped "PROGRAMMER BEWARE" . And such is the case, because PL/l 
is a permissive language allowing many statements and mixtures of data. 

The size and complexity of PL/l make learning the language a 
formidable task. The learning problem is compounded by the lack of PL/l 
literature. The present literature consists of one book and several documents 
published by IBM. IBM provides a few introductory student texts, program 
logic manuals, and an often revised reference manual. The introductory 
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texts provide a broad brush treatment of Pl/l for specific application areas 
and lack the detail necessary for writing a program. The logic manuals, 
containing flow charts and descriptions of the Pl/l compiler, are written 
for implementors . The reference manual, sometimes called the SRL 
manual, is the only available detailed description of PL/l. This manual 
describes PL/l using a syntax notation unfamiliar to most programmers, and 
this notation stops many from using the manual. Furthermore, the terminology 
used to describe PL/l is new or inconsistent with current usage: 1 of the 
same terms. However, most terminology is precisely defined, if one knows 
how to find the definition. As one student said about the manual, "It 
was written by a Philadelphia lawyer and must be read as such." If 
the quasi-programmer gets past the problem of reading the reference 
manual, he still has problems because the manual does not specify when 
to use a given feature and there is no literature available on this subject. 

The major problems one encounters when learning and using PL/l 
are a result of the size and complexity of PL/l. For example, PL/l provides: 

a. over eight data types not including over fourteen combinations 
of arithmetic data attributes; 

b. seventeen operators; 

c. thirty-three statements, most with at least one option; and, 

d. sixteen major classifications of attributes. 

The professional programmer has the background necessary to understand 
the relationships between the different facilities of PL/l. The quasi- 
programmer must be taught the relationships between the different data 
types, operators, statements, and attributes. He cannot be taught this 
in forty hours of class lectures. Yet one week is the duration of most 
PL/l training classes. Many pseudo-programmers will attend this type of 
class and, upon finishing the class, will have the false security that they 
have been told enough about PL/l to use it effectively. They haven't! 
The course, as outlined in the IBM PL/l coding Education Guide (R20-1018) 
only skims the surface of PL/l and presents none of the anomalies of the 
language . 
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The following is an example of a typical type of error that arises 
because of the many combinations of arithmetic data types available with 
PL/l. The programmer may describe data as having a scale of FIXED 
or FLOAT and a base of DECIMAL or BINARY. There are thus four possible 
combinations of scale and base: FIXED DECIMAL, FDCED BINARY, FLOAT 
DECIMAL, and FLOAT BINARY. In the 360 implementation, a data item 
described as FLOAT DECIMAL and FLOAT BINARY have the same machine 
representation; they are represented in hexadecimal floating point format. 
FIXED DECIMAL and FDCED BINARY data items have different machine 
representations; they are represented as packed decimal and binary data, 
respectively. Furthermore, the FIXED scale represents decimal or binary 
numbers that may have a fractional portion, i.e. , a scale factor or precision. 
This poses the problem of associating precision with a FDCED constant. 
For purposes of expression evaluation, an apparent precision is defined 
for real fixed-point constants to be (w,d) where w is the total number of 
digits in the constant and d is the number of digits specified to the right 
of the decimal point . 

Most programmers in the commercial application area are familiar 
with fixed decimal data. However, most programmers do not understand 
rational arithimetic. Because of PL/l rules governing evaluation of 
expressions, the expression (10 + (3/2)) yields a result of 1.50000000000000.* 
The same result occurs if the constants are replaced by three data items 
having precisions (2,0), (1,0), and (1,0). Qua si-programmers cannot 
understand why the result is not 11.5, but the main problem is that they 
probably may never realize that truncat ation can occur from the left . 

The qua si-programmer who has been using FORTRAN also has 
problems. In FORTRAN he uses integer and floating point data and tends 
to equate the FDCED DECIMAL or FLXED BINARY of PL/l with FORTRAN'S 
integer data. He will have the same problem as the commercial programmer 
with the expression (10 + (3/2)) . Another problem may be that algorithms 
no longer work when programmed in PL/l. For instance, the algorithm 
"compute (I-((l/2)*2)) and then check for zero" used for distinguishing 
between odd and even integers will not work in PL/l because there is no 
integer arithmetic. a 



* See footnote page 32 (RWM) 0Q X ^ /) 
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The many operators of PL/l coupled with the many data types and the 
ability of the compiler to interpret most expressions creates another set 
of problems for the qua si-programmer. In PL/l there are seventeen different 
operators divided into four types: arithmetic operators, comparison operators, 
bit-string operators, and string operators. There are accordingly two types 
of data which can be used with the operators: arithmetic data and string 
data. The operands of any operator need not be the same type as the 
operator nor the same type as each other. Thus it is correct to concatenate 
(a string operation) a float data item with a character string data item. It 
is also correct to use the arithmetic addition operator with two character 
string data items. Expressions with mixed data items, especially with 
arithmetic and string data, are usually written by mistake; however the 
compiler provides an interpretation for them. If the programmer is lucky, 
there may be some indication at execute time that conversion between 
arithmetic and string data is taking place. The qua si-programmer in his 
use of PL/l will probably write many statements that are incorrect, are time 
and space consuming, yet never know about it. 

Another area where the quasi-programmer may have trouble using 
PL/l is the interrupt operations . Although the interrupt operations provide 
the programmer with a flexible debugging aid, their concept is usually 
outside the knowledge of the quasi-programmer. The interrupt operation 
causes the suspension of normal program activities in order to perform a 
special action; after the special action, program activities may or may not 
resume at the point where they were suspended. Some of the interrupts 
are generated by hardware detected errors , some are the result of error 
detection by system routines, and some interrupts are generated, under 
programmer control, by the execution of the Pl/l SIGNAL statement. Those 
conditions which are not named and controlled by the programmer have 
standard actions associated with them which the programmer may override. 
There are two program checkout conditions which are enabled by the 
programmer. The first condition, SUBSCRIPTRANGE, occurs when a subscript 
is evaluated and found to lie outside its specified bounds . The second 
condition, CHECK (identifier-list) provides a snap/trace of the specified 
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identifiers. If the quasi-programmer masters the interrupt concept, he 
will have a powerful debugging aid. However, the debugging facilities 
of PL/l are a two-edged sword. Although they make debugging much easier 
than machine level debugging, they will consume vast amounts of time 
and computer storage if used in a production program. Thus the quasi- 
programmer will have to learn to use them discriminately and effectively. 

Because of the size and complexity of PL/l, there are many ways 
to program a given problem. One way may be better than another way. 
The quasi-programmer probably will never realize that he is using a given 
feature in a manner it was never intended. Also, because he never cares 
about generated code, he will never realize that the way he defines his 
problem data drastically affects the running time of his program. An 
example of data definition seriously affecting execution time follows . 

A simple card to tape routine was programmed two ways . In one 
program the data was declared as 80 one-character items (DCL CARD(80) C HAR(l)) , 
and in the other as one 80 character item (DCL C ARD CHAR(80)) . Other than 
the declare statement, both programs were identical. The first program 
(80 one-character items) to ojc approximate ly 150 minutes; the second program 
(one 80 character item) took ap proximately 7 minutes . A factor of 25! 

Unfortunately, there are many qua si-programmers. Hopefully 
PL/l will force them to understand more about computers , computer languages , 
compilers, and operating systems. If not, there will be many installations 
ordering more computers or bigger computers . 
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Freedom of Expression is not License for Anarchy * 
Mathew Myszewski 

Although PL/l has many forms for expressing the same problem sol- 
ution, and it would be hoped that the most natural means of expression were 
also the most efficient, error free, and free from anomalies; usually this 
is not the case. It is unfortunate that a language which has aspired to so 
much is so filled with traps for the unsuspecting. This in spite of the claim 
that "PL/l is organized so that any programmer, no matter how extensive 
his experience, can use it easily at his own level."** 

There are three kinds of traps that come to mind. First, and least 
detrimental, is to use a natural form of expression and find that it is 
inefficient. This has largely been discussed in the topic "Some Major 
Efficiency Questions in PL/l. " Next, the user of PL/l may use a natural 
form of expression and find that he gets incorrect results quite possibly 
without any warning. Lastly, simple errors in expression may cause com- 
pletely anomalous behavior simila r to the store in a wild l ocation that one 
frequently encounters in assembly language programming. Each of these 
traps is present in PL/l. 

Since efficiency questions have been treated elsewhere, we will 
only pause to note one example of this type of pitfall. Suppose a PL/l 
programmer has used the debugging forms of the ON statement and condition 
prefixes. When he is done debugging he removes all the ON statements to 
eliminate the debugging output. However, inadvertently or through innocence 



* Juster Norton, "The Dot and the Line", Random House, New York, 1963. 

** IBM Systems Reference Library, IBM System/360 Operations System, 
PL/l Language Specifications, File No. S360-29, Form C28-6571-4, p. 9. 
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he leaves in one or more CHECK type condition prefixes. These will not 
cause incorrect results or spurious printout but will use inordinate amounts 
of machine time. This is the perfidy of inefficiencies; correct results are 
produced but unnecessary machine time is used, often without the knowledge 
of the unsuspecting user. And if he does suspect, it is often extremely 
difficult to track down the cause of such inefficiencies . 

A few examples of incorrect results obtained without warning will 
suffice to give an idea of what is in store for the wary or unwary Pl/l user. 
Other cases will be left as an exercise for the production PL/l programmer. 
Consider the statement: 

A= 10 + 3/2; 

Who would suspect that the PL/l manual defines the result of this computation 
to be undefined? The reason is that the definition of fixed point arithmetic 
is such t hat the subtraction will cause an overflow which gives an undefined 
result*. (Note that the literals could have easily been variables of the 
same data type.) Other cases of this form of trap may be found in operator 
precedence and other rules for expression evaluation. 

Lastly, we will consider some examples of anomalous behavior. With 
the exception of assembly language programming, pointers were never so 
accessible to run-of-the-mill programmer before. Since the pointer may be 
over-laid with, for example, floating point data using the CELL, the possibility 
exists for execution of random fetches and stores in data, program, and other 
areas of storage. Fortunately, the programmer in PL/l has the opportunity tc 
do SUBSCRIPTRANGE testing and catch a principal cause of these anomalies 
in FORTRAN. 
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* The difference in the statement here and the one on page 28 are a result of ^ 
the PL/l definition having been changed between the times when the -■** X 



respective authors studied the issue. (RWM) 



1 

-32- ** 

V 



These few items can and will be extended considerably as more 
experience is gained with PL/l. I suspect that new categories of traps 
will arise, such as conflict of user identifiers with PL/l keywords and 
built-in function names , but those given above will continue to ensnare 
even the well informed . 
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PL/l Problems for the Implemented 
R.W. Mitchell 

There are two general problems facing the implementor of PL/l. 
The first is "What is.Pl/l?" and the second is a collection of technical 
"How should such issues be done?" 

Determining "What PL/l is" is a difficult issue because of the 
size of PL/l and because of the form of the definition of PL/l (which will 
be considered in another section). One of the most evident characteristics 
of any of the definitions of PL/l is its size. The total number of pages is 
always in the hundreds . The intricate interdependies of the language are 
very difficult to identify and understand under these conditions . 

This has resulted in most of the implementations of PL/l having 
been designed with less than complete understanding of the language and 
later being revised as a number of issues became apparent. 

The unusual technical problems facing the implementor center 
around the following 

attribute structure, 
procedure linkage , 
ON-conditions , 
asynchronous processing, and 
optimization. 

The attribute structure is large and the rules for completing the 
set of attributes for a partially declared identifier are fairly complex in some 
cases. Because of this large attribute structure the processing of all data 
references is also quite involved. 
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The basic problem in procedure linkage is the potential variability 
of entry points (and, hence, argument list), attributes of arguments, and 
return points . This results in very inefficient, code for the simple cases 
or very complex logic for the implementation. 

The ON-conditions and asynchronous processing present the 
problems of flow of control paths which do not follow a convenient 
hierarchical pattern. 

The question of optimization is dependent on recognizing the special 
cases which permit deletion of unnecessary actions. Once again the size 
of the language (hence, number of cases) and the variability of the specifics 
of the attributes create the problems . 

The design goals of Pl/l include modularity partially to ease the 
implementor's task of providing compilers of reasonable size and efficiency. 
This has led some to suggest very modularized compilers as a possibility. 
It is my opinion that we will be a couple years just learning how to implement 
PL/l with all of its features and it won't be until after that time that the 
potential for modularized PL/T compilers can be properly investigated. 
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